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Remarks/Arguments 

Reconsideration of this application is requested. 
Claim Status 

Claims 1-4 and 8-24 are pending. Since no claims are amended, added or 
canceled by this response, no listing of claims is required under 37 CFR 1.121. 
Claim Rejections - 35 USC 103(a) 

Claims 1-4 and 8-24 are rejected under 35 USC 103(a) as obvious over 
Zakurdaev (US 2002/0073182) in view of Gong (US 2001/0044819) and Beyda (US 
7,120,927). In response, applicant traverses the rejections. 

Claims 1, 2, 8 and 17 

In the present invention, a first network device initiates, logs into and 
establishes a first held TCP/IP connection with a relay server and a second network 
device initiates, logs into and establishes a second held TCP/IP connection with the 
relay server. Data is then relayed between the first and second network devices via 
the relay server using the same first and second held TCP/IP connections in 
accordance with connection demand information. Importantly, the connections that 
are initiated and established by the first and second network devices are the same 
connections that are used in relaying data between the network devices. In 
contrast, the combination of Beyda and Zakurdaev teaches away from this critical 
feature of the invention. 

Beyda is directed to a first and second user that registers information in an 
account database 275. As shown in FIG. 5, a user in step 1000 first accesses a 
website of relay server 102 and then submits registration information such as 
name, address, credit card and e-mail alias information. In step 1006, the user 
exits or logs off from the relay server 102. Importantly, a subsequent relay 
communication between a user A and B cannot use the registration connection since 
the registration connection between a user A or B and the relay server 102 is 
disconnected once the user has inputted the registration information . 
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For example, if user A has registered information such as an e-mail alias, and 
user B attempts to send an e-mail to user A's alias, relay server 102 first determines 
whether user B has registered with relay server 102 (FIG. 6; step 1204). If user B is 
registered, relay server 102 forwards the e-mail to user A. If not registered, user B 
is prompted to register information before forwarding the e-mail. In either case, 
given that the registration connection between relay server 102 and user A is 
disconnected, relay server 102 must necessarily form a new forwarding connection 
between relay server 102 and user A to forward the e-mail. Thus, Beyda does not 
teach using the registration connections to relay data between users A and B. In 
order to relay e-mails between a user A and B, a forwarding connection initiated by 
relay server 102 is required. 

Moreover, Zakurdaev teaches a one-way connection process where a 
connection is formed from a terminal to the relay server and then from the relay 
server to an ISP (FIG. 2). As described above, Beyda provides a similar one-way 
connection processes for relay communication. Thus, it makes no sense to combine 
the registration process of Beyda with the relay communication of Zakurdaev since 
the registration connections initiated by a first and second user are disconnected 
before relay communication. 

In sum, independent claims 1, 2, 8 and 17 require that the first and second 
held TCP/IP connections be established by the first and second network devices, 
respectively, and those same connections be used to relay data between the first and 
second network device. Beyda teaches registration connections initiated and 
established by a user A and B. However, those connections are clearly not used to 
relay data between users A and B. When Beyda is considered in its entirety, it is 
clear that the combination of Beyda and Zakurdaev teaches away from the claimed 
invention (MPEP 2141.02). Gong is directed to an unsigned Java applet and does 
not remedy the deficiencies of Beyda and Zakurdaev. 
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Since Beyda, Zakurdaev and Gong do not teach or suggest each and every 
element of claims 1, 2, 8 and 17, it cannot render those claims or claims dependent 
thereon obvious. The rejections under 35 USC 103(a) should be withdrawn. 

Claims 21-24 

Dependent claims 21-24 each recite a connection holding command that is 
received at the relay server via a held TCP/IP connection and a response that is 
returned to the network device that sent the connection holding command. As 
disclosed in paragraph 0027 and FIG. 2, the connection holding command maintains 
and holds the TCP/IP connection between a network device and relay server. The 
Action cites Zakurdaev as disclosing a connection holding command sent via the 
first or second held TCP/IP connection to the relay server. Applicant strongly 
disagrees. 

Zakurdaev is directed to delivering and loading an IP address of a user- 
selected Internet Service Provider (ISP) into the user terminal so that the user 
terminal can access the Internet through the ISP. Zakurdaev simply transmits a 
command and receives a response and does not teach applicant's connection holding 
command. In particular, a user terminal 316, 324 or 336 transmits a request for an 
IP address (DHCPDISCOVER signal) to a gateway device 312 which then forwards 
the DHCPDISCOVER signal to the Network Operations Center (NOC) 304. Once 
the proper ISP is determined, NOC 304 forwards the DHCPDISCOVER signal to 
the proper ISP (i.e. 344, 348 or 352). The ISP responds with a DHCPOFFER signal, 
including the ISP address of the ISP, which is forwarded to NOC 304, to gateway 
device 312 and finally to the user terminal where it is automatically loaded 
(paragraphs 0044-0046). 

The DHCPDISCOVER signal is merely an IP address request that has no 
bearing on the maintenance and holding of a connection between a user terminal 
316, 324 or 336 and a NOC 304. Therefore, there is no disclosure or suggestion in 
Zakurdaev that a held TCP/IP connection is maintained and held between ISPs 344, 
348 or 352 and gateway device 312 by a connection holding command originating 

Page 4 of 5 

WVLA - 081800/000177 - 349657 vl 



Appl. No. 10/045,698 
Reply dated July 2, 2007 



Atty. Ref. 81800.0177 
Customer No. 26021 



Reply to Office Action of April 10, 2007 

from a user terminal. The ancillary references do not remedy the deficiencies of 
Zakurdaev. For at least these reasons, the rejections of claims 21-24 under 35 USC 
103(a) should be withdrawn. 
Conclusion 

This application is in condition for allowance. The Examiner is requested to 
telephone the undersigned to resolve any issues that remain after entry and 
consideration of this response. Any fees dues with this response may be charged to 
our Deposit Account No. 50-1314. 



Respectfully submitted, 
HOGAN & HARTSON L.L.P. 




Date: July 2, 2007 



Tj^jflVL Schmelzer 
Registration No. 36,667 
Attorney for Applicant(s) 



1999 Avenue of the Stars, Suite 1400 
Los Angeles, California 90067 
Phone: 310-785-4600 
Fax: 310-785-4601 
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